fix(hooks): repair a stale SessionEnd hook instead of only installing once - #7

Problem

The SessionEnd hook command embeds an absolute path to the binary, so renaming the project (claude-recall → code-recall) left existing installs pointing at a command that no longer exists. The hook then failed silently on every session end:

ModuleNotFoundError: No module named 'claude_recall.cli'

The migration for exactly this case was already present — LEGACY_COMMAND_NAMES and _hook_mentions_app — but it was unreachable:

is_first_run = not args.db.exists()
if is_first_run and not HOOKS_MARKER.exists():   # false for anyone with an index
    _auto_install_hooks()

Anyone past their first run could never reach the rewrite branch, so a broken hook stayed broken.

Changes

• Split repair from install. An existing hook is refreshed whenever it differs from the desired config; a missing hook is only added on first run, so one the user deleted is not resurrected. Writes happen only on an actual change, so ordinary runs leave settings.json untouched.
• Stop destroying settings.json when it cannot be parsed. The read error was swallowed with pass and the resulting empty dict written straight back, replacing every unrelated key with just hooks. Verified against the pre-fix code: a truncated settings file was left with only ['hooks'], losing model and permissions.
• Atomic writes via temp file + rename, so an interrupted write cannot truncate the file.

Notes

_cmd_index does not call _first_run_setup, so the hook's own index --quiet never rewrites settings — repair rides on interactive commands only. It has to: a hook pointing at a missing binary never executes and so cannot repair itself.

Testing

11 new tests (339 total, all passing), plus compileall and check_version.py. Confirmed as genuine regression tests by running the same scenario against main: old code leaves the stale command in place, new code repairs it while preserving unrelated keys.

🤖 Generated with Claude Code